Infleqtion at IEEE Quantum Week 2026: Advancing Fault-Tolerant Quantum Computing with NVIDIA CUDA-Q Logical

My colleagues and I are excited to be at IEEE Quantum Week 2026 to share our work on quantum error correction using NVIDIA CUDA-Q Logical. How is Infleqtion using NVIDIA CUDA-Q Logical to advance fault-tolerant quantum computing? During IEEE Quantum Week, we are excited to preview work that our team has developed through early access to NVIDIA CUDA-Q Logical, which was just announced. This new logical layer extends the CUDA-Q open platform for Quantum-GPU Supercomputing with a toolset designed to accelerate the execution of fault-tolerant quantum algorithms. At its core, our work using CUDA-Q Logical centers on quantum error correction (QEC). We integrated CUDA-Q Logical with the qLDPC software package, which we open-sourced while working alongside researchers from JPMorgan Chase last year. Specifically, we used CUDA-Q Logical and the qLDPC software to construct a hypergraph-product simplex (HGPS) code, generate its stabilizers and logical operators, and then set up its underlying algebra. The end result is a validated code block with 98 physical data qubits and 18 logical qubits – a ~5x improvement in logical-to-physical ratio (i.e. code rate) over previous codes like surface code. What does an 18.4% encoding rate tell us, and what does it leave out? Many familiar QEC constructions devote a large number of data qubits to each logical qubit. High-rate qLDPC codes change that arithmetic by encoding multiple logical qubits in one block while keeping each stabilizer check sparse. The appeal is obvious: if the rest of the architecture cooperates, more of the machine can carry useful logical information. For the HGPS instance in our prototype, 98 physical data qubits encode 18 logical qubits, a code rate of about 18.4%. The code contains 49 X checks and 49 Z checks, each of weight six. The canonical logical representatives returned by qLDPC software have weight four. Those numbers are promising, but they are not a hardware resource estimate. Syndrome ancillas, movement, scheduling, readout, control, and classical decoding all sit outside the 18/98 ratio. A code is high-rate on paper only; a useful architecture has to preserve that advantage through the rest of the stack. How do we construct a code that encodes 18 logical qubits in 98 data qubits? Next, we show how to build the HGPS code from a seed. We begin with a cyclic classical simplex code. Setting r = 3 gives a seven-bit seed. Its parity-check matrix comes from the binary polynomial 1 + x + x³ and has the familiar [7,3,4] parameters: seven bits, three encoded bits, and distance four. The imports, constants, and circulant helper below make the full construction readable within this post: import numpy as np from qldpc.codes import ClassicalCode, HGPCode from qldpc.objects import Pauli as QldpcPauli import qlx R = 3 SEED_LENGTH = 2**R - 1 EXPECTED_PARAMS = (98, 18, 4) def circulant_shift(size: int) -> np.ndarray: return np.roll(np.eye(size, dtype=int), 1, axis=1) shift = circulant_shift(SEED_LENGTH) simplex_check = ( np.eye(SEED_LENGTH, dtype=int) + shift + np.linalg.matrix_power(shift, 3) ) % 2 simplex = ClassicalCode(simplex_check) assert simplex.get_code_params() == (7, 3, 4) We then take the square hypergraph product of that seed. qLDPC software constructs the X- and Z-check matrices and a canonical set of logical Pauli operators. The result has published parameters [[98,18,4]]: 98 data qubits, 18 logical qubits, and distance four. This is the HGPS construction discussed by Yang et al. (from the lab of Professor Fred Chong, Infleqtion’s Chief Scientist for Quantum Software) for reconfigurable neutral-atom arrays. hgps_qldpc = HGPCode(simplex, set_logicals=True) assert hgps_qldpc.get_code_params() == EXPECTED_PARAMS hx_dense = np.asarray(hgps_qldpc.matrix_x, dtype=int) % 2 hz_dense = np.asarray(hgps_qldpc.matrix_z, dtype=int) % 2 lx_dense = np.asarray( hgps_qldpc.get_logical_ops(QldpcPauli.X), dtype=int ) % 2 lz_dense = np.asarray( hgps_qldpc.get_logical_ops(QldpcPauli.Z), dtype=int ) % 2 assert hx_dense.shape == hz_dense.shape == (49, 98) assert lx_dense.shape == lz_dense.shape == (18, 98) Before passing that algebra to CUDA-Q Logical, we check it directly. The X and Z stabilizers must commute; the logical operators must commute with the opposite stabilizer family; and each logical X must anticommute with exactly its paired logical Z. The following assertions test those relationships over GF(2): assert not np.any((hx_dense @ hz_dense.T) % 2) assert not np.any((lx_dense @ hz_dense.T) % 2) assert not np.any((lz_dense @ hx_dense.T) % 2) assert np.array_equal( (lx_dense @ lz_dense.T) % 2, np.eye(EXPECTED_PARAMS[1], dtype=int), ) Together, these checks establish that the matrices define the intended CSS code and logical basis, ready for CUDA-Q Logical’s placement and QEC compilation stages. How does CUDA-Q Logical use the code built with qLDPC software? qLDPC software supplies reusable code mathematics, while CUDA-Q Logical supplies the logical ownership, block allocation, and compilation model. The code interface in CUDA-Q Logical takes sparse row supports. A small adapter converts the dense NumPy arrays, after which the qLDPC software-generated checks and logical operators can be declared as an 18-port CUDA-Q Logical code: def row_supports(matrix) -> tuple[tuple[int, ...], ...]: dense = np.asarray(matrix, dtype=int) % 2 return tuple( tuple(int(column) for column in np.flatnonzero(row)) for row in dense ) @qlx.code class HGPS98: block = qlx.codes.CSSBlock(data=98, sx=49, sz=49) d = qlx.codes.Distance.claimed( 4, provenance=( 'Yang et al., arXiv:2602.14273, Definition 8 and Table 3' ), ) hx = row_supports(hx_dense) hz = row_supports(hz_dense) lx = row_supports(lx_dense) lz = row_supports(lz_dense) assert (HGPS98.n, HGPS98.k, HGPS98.d.value) == EXPECTED_PARAMS We use the distance-four value reported by Yang and colleagues and carry its provenance directly in the code. The integration validates the code algebra and makes the physical implementation assumptions explicit for the next phase. How does CUDA-Q Logical compile a logical measurement into an encoded workflow? The compiler workflow begins with an application-level objective: measure a joint X-by-Z observable on two distinct logical qubits. The encoding is selected later in the compilation pipeline: @qlx.objective def joint_xz( left: qlx.types.logical_qubit, right: qlx.types.logical_qubit, ) -> tuple[qlx.types.logical_qubit, qlx.types.logical_qubit, bool]: left, right, parity = qlx.mpp( qlx.types.X(left) @ qlx.types.Z(right) ) return left, right, parity The gadget supplies the encoded implementation and maps the two operands to ports q0 and q1 of the same HGPS block: @qlx.gadget( implements=joint_xz, logical_ports={ joint_xz.operands.left: HGPS98.default_encoding.ports.q0, joint_xz.operands.right: HGPS98.default_encoding.ports.q1, }, ) def hgps_joint_measurement( block: qlx.patch[HGPS98], ) -> tuple[qlx.patch[HGPS98], bool]: block, _ = qlx.extract_syndrome(block) block, parity = qlx.mpp( qlx.types.X(block[0]) @ qlx.types.Z(block[1]) ) return block, parity We then define a two-qubit logical memory, bind it to the HGPS98 encoding, and ask CUDA-Q to use that encoding: device_builder = qlx.devices.DeviceBuilder('HGPSP2Device') memory = device_builder.logical.add_memory( capacity=2, capabilities=(qlx.architecture.capability.logical_compute,), ) device_builder.qec.bind(memory, encoding=HGPS98) HGPSP2Device = device_builder.build() @qlx.program def packed_hgps_probe() -> bool: values = qlx.allocate(2, state=qlx.types.zero) values[0], values[1], parity = joint_xz(values[0], values[1]) qlx.discard(values) return parity The placement pass keeps the logical values together while leaving the choice of QEC block to the next compilation stage: p1 = qlx.compiler.place( packed_hgps_probe, device=HGPSP2Device, placement=lambda values: (qlx.architecture.colocate(values[0]),), ) assert p1.qec_selection is None Finally, the QEC compilation stage selects the encoding. The assertions are the result we care about here: one validated HGPS block contains two distinct logical owners with one allocation, one deallocation, and one product measurement. p2 = qlx.compile( p1, pipeline=qlx.compiler.pipelines.qec(), device=HGPSP2Device, policy={ 'qec_blocks': ( qlx.codes.qec_block(p1.values[0], code=HGPS98), ), }, ) counts = qlx.analysis.count(p2) assert len(p2.qec_selection.blocks) == 1 assert len(p2.qec_selection.blocks[0].owners) == 2 assert counts.operation_counts['alloc'] == 1 assert counts.operation_counts['dealloc'] == 1 assert counts.operation_counts['measure_product'] == 1 What has the integration validated so far? The integration validated four concrete results: The seven-bit simplex seed has [7,3,4] parameters, and its square hypergraph product has published [[98,18,4]] parameters. The stabilizer matrices commute and the 18 logical X/Z pairs have the expected canonical pairing. The imported CUDA-Q code has 49 X checks, 49 Z checks, and 18 logical ports. The compiled workflow preserves two distinct logical owners within one encoded block. This integration focuses on code construction, logical ownership, and compilation. In coming work, we plan to extend this workflow through physical syndrome extraction, neutral-atom noise modeling, detector generation, and decoder benchmarking. Our earlier AI-accelerated QEC work explored decoding with open models using NVIDIA Ising. The HGPS integration described here addresses the complementary code-and-compiler layer, giving us a clean path to bring advanced decoders into the same full-stack workflow. See our earlier AI-accelerated QEC post for more on that work. Why explore high-rate qLDPC codes on neutral-atom hardware? High-rate qLDPC codes are especially interesting when the hardware can support parallel interactions and flexible connectivity. Reconfigurable neutral-atom arrays offer a natural setting for that investigation. The architecture described by Yang et al. uses parallel physical operations and code-aware logical structure to reduce footprint while preserving space-time efficiency. For our team, the opportunity is to trace that promise through a real machine model. That means accounting for where ancillas live, how atoms move, which checks can run in parallel, how leakage and loss appear in readout, and whether the classical decoder can keep up with the syndrome stream. Logical performance emerges from the coordination of hardware, control, compilation, and classical compute. What comes next on the path to physical execution? We aim to extend this validated logical block into a controlled systems workload across five areas: Declare a physical extraction plan, including ancilla resources, check-to-data interactions, and an explicit schedule. Attach realistic neutral-atom noise semantics, including loss and leakage where supported. Derive detector meaning from that physical plan and generate a detector error model from the same artifact used for simulation. Connect a compatible decoder, potentially through qLDPC’s decoder interfaces, and measure accuracy, throughput, and latency while keeping the logical objective fixed. Compare resource and performance tradeoffs across codes and architecture choices while holding the workload and metrics fixed. CUDA-Q Logical is an open, extensible layer that provides the structure for these comparisons. The workload can remain fixed while the QEC code, architecture, schedule, noise model, simulator, and decoder become explicit choices. That creates a path to apples-to-apples comparisons and resource estimates built from one auditable, reproducible experiment. How will CUDA-Q Logical support full-system evaluation? The 18.4% data-qubit encoding rate gives us a compelling starting point for full-stack evaluation. Through CUDA-Q Logical, we now have an inspectable, executable representation of the code’s logical structure, backed by assertions that state exactly what has been checked. From here, we can add the physical schedule, realistic noise, detector semantics, and decoding while keeping the logical workload fixed. That continuity is what makes CUDA-Q Logical valuable to our program: each layer can be evaluated in context, and the high-rate advantage can be traced through the full system. Throughout this week at IEEE Quantum Week, we look forward to engaging with the broader quantum community to turbo-charge the path to logical qubits and to useful quantum computing. We acknowledge the use of GPT-5.6 Sol in Codex for AI-assisted software development for the integration.